API 安全之资产管理

在企业安全实践中，我们经常遇到一个令人头疼的问题：引发安全事件的API往往不在我们的SDLC版本管理范围内。

记得有一次我们公司遭遇安全事件，攻击者利用了一个从未登记在册的"影子 API"，导致 10 万用户信息泄露。事后分析发现，这个API要么是测试环境遗漏了，要么就是域名我们压根没见过。还有一次因为支付API的权限管控疏漏，被恶意调用造成了百万资金损失，而这个API在正式文档中根本没有记录。

这些血淋淋的案例让我意识到一个核心问题：如果连"有多少 API、在哪里、在做什么"都不清楚，谈何安全防护？

1. 必要性和背景

企业API管理的现状困境

在我们公司的实际运营中，我观察到API管理存在几个典型问题：

1.1 影子API泛滥 我们的API数量在3年内从500个飙升到3000+，其中近40%是业务团队为快速上线功能而临时开发的"影子API"。这些API往往：

• 没有经过安全评审
• 不在版本控制范围内
• 缺乏文档记录
• 权限配置混乱

1.2 测试环境失控 开发团队经常在测试环境部署临时API进行调试，这些API：

• 可能包含生产数据
• 安全配置不完整
• 容易被遗忘和遗漏

1.3 域名管理混乱 随着微服务架构普及，我们发现了大量从未见过的域名：

• 第三方服务集成
• 内部服务拆分
• 临时测试域名

根据Gartner的研究报告，企业平均拥有的"影子API"数量是已知API的3-5倍，这意味着大部分API资产处于"失控"状态。

2. 收集API的方法

说到怎么把 API 挖干净，我不追求一招制胜，而是两条线并行：能“看到”的先尽量收全，正在“发生”的再用数据佐证。前者给我们全貌，后者给我们事实。

2.1 主动收集 - "地毯式搜索"

我先把能拿到的仓库、前端工程和文档一个不落地梳理。后端这边，我优先从网关配置、OpenAPI/Swagger、以及各个微服务的路由定义入手；前端这边，我专盯硬编码域名、BFF 直连后端、以及旧版本里遗留的接口；文档中心则是对照物，用来对齐命名、注释和责任人。

每发现一条接口，我都会给它打全标签：服务名、方法、路径模板、环境、Owner、最后变更时间。主动这条线的目标只有一个——把“理论上应该存在的 API”尽量收全，哪怕先不完美。

2.2 被动收集 - "流量分析大法"

主动之外，我一定会上“被动线”。我会在网关和负载均衡打开访问日志，把真实调用过的 host、path、method 全部拉出来，再做路径模板化，避免被数字 ID、UUID 之类的参数干扰。业务和应用日志则用来补全调用上下文，比如 trace_id、用户类型、状态码分布等。

如果条件允许，我会做少量的镜像/采样，但只保留元数据和结构摘要，绝不落盘敏感载荷。被动这条线的意义在于：它能告诉我“实际有哪些接口在被用”，并且暴露出文档之外的影子接口。

3. 落地过程

我把落地拆成四个动作：盘点 → 标准化 → 合并 → 分级。结构保留，但我更强调“把事说清楚”。每一步我都只做三件事：先把手里有什么搞清楚，再把口径拉齐，最后把结果沉淀成团队都能用的产物。

3.1 盘点（可见性就绪）

这一阶段的目标就是把可见性补齐。我把代码、文档、域名/服务清单、以及网关和业务日志一起拉到桌面上，先立“数据源清单”和“责任人矩阵”，再用网关日志去校准“真实在用”的接口。结果是第一版接口台账，覆盖率从约六成拉到九成五以上，每一条记录都能追溯到来源与 Owner。

3.2 标准化（口径统一）

真正的阻力来自口径不一：同一接口在代码、日志、文档里的写法各不相同。我把路径先模板化（数字 ID、UUID、长 token 统一占位），版本作为独立维度管理，并用“method + path_template + service/host”生成唯一签名。只有当 signature、env、owner、auth、data_classification 等元数据齐备时，它才算“准生产资产”，可以进入后续环节。

3.3 合并（事实优先）

合并阶段我坚持“事实优先”的顺序：生产流量证据 > 网关配置 > 代码声明 > 文档描述。冲突项统一进“复核池”，我按周拉齐责任人确认口径；所有资产都会带着置信度分和来源轨迹。最终产物是一张去重后的主资产表（同一 signature 只保留一条），并保留多源溯源信息，让噪音迅速下降。

3.4 分级（风险落地）

分级不靠拍脑袋，我只看三件事：数据敏感性（有没有 PII/支付/密钥）、业务影响（是不是触钱/触单/触号）、操作权限（只读/变更/管理）。评分落到 1–5 级，4 分及以上一律视作高风险，自动挂上鉴权、审计、限流、脱敏等控制。最后我们沉淀出一张“分级—控制映射表”，后续治理、审计和改造都以此为准。

4. 收益

可见性与统一口径

• 影子API、测试口残留、跨域直连一眼可见；前端已下线但仍在网关日志出现的“僵尸接口”被标记
• 同一接口多名多路径的问题被收敛，按 signature 管理，版本、环境、Owner 清晰

风险识别与优先级

• 未纳入渗透测试范围的接口自动挑出（新发现、无鉴权、管理/删除等高危操作）
• 响应中携带 PII、字段过度暴露、错误信息泄露、未限流等异常被归类入队
• 测试/灰度域名对公网开放、老版本仍可访问等“表里不一”的暴露面被识别

精简与治理

• 前端已下线但后端仍有流量的接口进入下线/替换计划
• 重复或功能重叠的接口合并；跨团队接口的归属与审批路径被厘清
• CI/CD 接入“开发即登记”，非常规变更在上线前被拦截

运营度量与协作

• 以风险等级驱动的工作队列，安全测试与修复资源更聚焦
• 资产变更、策略落地、整改闭环可追溯，复盘与审计成本显著下降
• 管理看板呈现覆盖率、准确率、违规类型趋势，沟通对齐更高效

这些收益的本质，是把“看不见的风险”转化为“可管理的工作项”，再用统一口径和流程把它们持续压下去。

API资产识别与管理不是一次性的项目，而是一个持续演进的过程。 只有建立起完善的管理机制，企业才能在享受API带来的业务价值的同时，有效控制安全风险，真正实现"安全赋能业务"的目标。

API资产数据表结构